Webpack 性能优化

这篇文章的优化内容是建立在 webpack 4.x 上的,后面也会有 webpack 5.x 相关的介绍

优化方式总览

加快构建速度(打包速度)

使用 speed-measure-webpack-plugin 插件可以测量各个插件和loader所花费的时间,量化打包速度,判断优化效果

  1. 缩小文件的搜索范围(配置include/exclude resolve.modules resolve.mainFields alias noParse extensions)
    1. 通过 exclude、include 配置来确保转译尽可能少的文件
    2. 优化 resolve.modules 配置
    3. 优化 resolve.mainFields 配置
    4. alias
    5. noParse
    6. extensions
  2. 在一些性能开销较大的 loader 之前添加 cache-loader,将结果缓存中磁盘中
  3. 使用 happypack 开启多进程打包
  4. 除了使用 Happypack 外,我们也可以使用 thread-loader 开启多进程打包 loader
  5. 使用 HardSourceWebpackPlugin 为模块提供中间缓存,第二次构建可大量节约时间
  6. 使用 IgnorePlugin 忽略第三方包指定目录,例如 moment 的本地语言包
  7. 使用 webpack-parallel-uglify-plugin 开启 JS 多进程压缩

减少打包文件体积

引入 webpack-bundle-analyzer 分析打包后的文件,判断哪些包还可以拆分和优化

  1. 使用 externals 配置,然后将 JS 文件、CSS 文件和存储在 CDN
  2. 使用 DllPlugin(动态链接库)将 bundles 拆分,使用 DllReferencePlugin(索引链接) 对 manifest.json 引用,让一些基本不会改动的代码先打包成静态资源,避免反复编译浪费时间
  3. 使用 optimization.splitChunks 配置抽离公共代码
  4. 使用 IgnorePlugin 忽略第三方包指定目录,例如 moment 的本地语言包(重复)
  5. 使用 url-loader 或 image-webpack-loader 对图片进行转化或者压缩处理
  6. 优化 SourceMap,开发环境推荐: cheap-module-eval-source-map,生产环境推荐: cheap-module-source-map
  7. 按需加载,项目中的路由懒加载
  8. webpack自身的优化:
    1. tree-shaking,在生产环境下,会自动移除没有使用到的代码
    2. scope hosting 作用域提升,变量提升,可以减少一些变量声明
    3. babel 配置的优化,配置 @babel/plugin-transform-runtime,重复使用 Babel 注入的帮助程序,以节省代码大小的插件。

加快 Webpack 构建速度(打包速度)

使用 speed-measure-webpack-plugin 插件测量打包速度

使用 speed-measure-webpack-plugin 插件可以测量各个插件和 loader 所花费的时间,量化打包速度,对比前后的信息,判断优化效果。

使用方式很简单,可以直接用其来包裹 Webpack 的配置:

1
2
3
4
5
6
7
8
9
//webpack.config.js
const SpeedMeasurePlugin = require("speed-measure-webpack-plugin");
const smp = new SpeedMeasurePlugin();

const config = {
//...webpack配置,不用在写 module.exports
}

module.exports = smp.wrap(config);

1.缩小文件的搜索范围(配置include/exclude resolve.modules resolve.mainFields alias noParse extensions)

exclude/include

在使用 Loader 时可以通过 test 、 include 、 exclude 三个配置项来命中 Loader 要应用规则的文件。 为了尽可能少的让文件被 Loader 处理,可以通过 include 去命中只有哪些文件需要被处理。

exclude 指定要排除的文件,include 指定要包含的文件。exclude 的优先级高于 include,在 include 和 exclude 中使用绝对路径数组,尽量避免 exclude,更倾向于使用 include。

例如在配置 babel-loader 时,可以这样:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
const path = require('path');
module.exports = {
module: {
rules: [
{
// 如果项目源码中只有 js 文件就不要写成 /\.jsx?$/,提升正则表达式性能
test: /\.js$/,
// babel-loader 支持缓存转换出的结果,通过 cacheDirectory 选项开启
use: ['babel-loader?cacheDirectory'],
// 只对项目根目录下的 src 目录中的文件采用 babel-loader
include: path.resolve(__dirname, 'src'),
},
]
},
};

优化 resolve.modules 配置

使用 resolve 配置 webpack 去哪些目录下寻找第三方模块

当安装的第三方模块都放在项目根目录下的 ./node_modules 目录下时,没有必要按照默认的方式去一层层的寻找,可以指明存放第三方模块的绝对路径,以减少寻找,配置如下:

1
2
3
4
5
6
7
8
9
const path = require('path');
module.exports = {
//...
resolve: {
// 使用绝对路径指明第三方模块存放的位置,以减少搜索步骤
// 其中 __dirname 表示当前工作目录,也就是项目根目录
modules: [path.resolve(__dirname, 'node_modules')],
}
}

优化 resolve.mainFields 配置

resolve.mainFields 用于配置第三方模块使用哪个入口文件

为了减少搜索步骤,在你明确第三方模块的入口文件描述字段时,你可以把它设置的尽量少。 由于大多数第三方模块都采用 main 或 index 字段去描述入口文件的位置,可以这样配置 Webpack:

1
2
3
4
5
6
module.exports = {
resolve: {
// 采用 main 或 index 字段作为入口文件描述字段,以减少搜索步骤
mainFields: ['main', 'index'],
},
};

这个配置一般很较少用,要注意所有第三方模块的入口文件。

resolve.alias

resolve.alias 配置项以通过别名的方式来映射一个路径,能让 Webpack 更快找到路径。

例如使用以下配置:

1
2
3
4
5
6
// Webpack alias 配置
resolve:{
alias:{
components: './src/components/'
}
}

当你通过 import Button from ‘components/button’ 导入时,实际上被 alias 等价替换成了 import Button from ‘./src/components/button’。

默认情况下 Webpack 会从入口文件 ./node_modules/react/react.js 开始递归的解析和处理依赖的几十个文件,这会时一个耗时的操作。 通过配置 resolve.alias 可以让 Webpack 在处理 React 库时,直接使用单独完整的 react.min.js 文件,从而跳过耗时的递归解析操作:

1
2
3
4
5
6
7
8
9
10
module.exports = {
resolve: {
// 使用 alias 把导入 react 的语句换成直接使用单独完整的 react.min.js 文件,
// 减少耗时的递归解析操作
alias: {
'react': path.resolve(__dirname, './node_modules/react/dist/react.min.js'), // react15
// 'react': path.resolve(__dirname, './node_modules/react/umd/react.production.min.js'), // react16
}
},
};

除了 React 库外,大多数库发布到 Npm 仓库中时都会包含打包好的完整文件,对于这些库你也可以对它们配置 alias。

但是对于有些库使用本优化方法后会影响到后面要讲的使用 Tree-Shaking 去除无效代码的优化,因为打包好的完整文件中有部分代码你的项目可能永远用不上。 一般对整体性比较强的库采用本方法优化,因为完整文件中的代码是一个整体,每一行都是不可或缺的。 但是对于一些工具类的库,例如 lodash,你的项目可能只用到了其中几个工具函数,你就不能使用本方法去优化,因为这会导致你的输出代码中包含很多永远不会执行的代码。

alias 还支持 $ 符号来缩小范围到只命中以关键字结尾的导入语句:

1
2
3
4
5
resolve:{
alias:{
'react$': '/path/to/react.min.js'
}
}

react$ 只会命中以 react 结尾的导入语句,即只会把 import ‘react’ 关键字替换成 import ‘/path/to/react.min.js’。

noParse

如果一些第三方模块没有 AMD/CommonJS 规范版本,可以使用 noParse 来标识这个模块,这样 Webpack 会引入这些模块,但是不进行转化和解析,从而提升 Webpack 的构建性能 ,例如:jquery 、lodash。

在上面的 优化 resolve.alias 配置 中讲到单独完整的 react.min.js 文件就没有采用模块化,让我们来通过配置 module.noParse 忽略对 react.min.js 文件的递归解析处理, 相关 Webpack 配置如下:

1
2
3
4
5
6
7
8
9
const path = require('path');

module.exports = {
module: {
// 独完整的 `react.min.js` 文件就没有采用模块化,忽略对 `react.min.js` 文件的递归解析处理
// noParse 属性的值是一个正则表达式或者是一个 function
noParse: [/react\.min\.js$/] // /jquery|lodash/
},
};

resolve.extensions

webpack 会根据 extensions 定义的后缀查找文件(频率较高的文件类型优先写在前面),
默认是 extensions: ['.js', '.json']

也就是说当遇到 require(‘./data’) 这样的导入语句时,Webpack 会先去寻找 ./data.js 文件,如果该文件不存在就去寻找 ./data.json 文件,如果还是找不到就报错。

如果这个列表越长,或者正确的后缀在越后面,就会造成尝试的次数越多,所以 resolve.extensions 的配置也会影响到构建的性能。 在配置 resolve.extensions 时你需要遵守以下几点,以做到尽可能的优化构建性能:

  • 后缀尝试列表要尽可能的小,不要把项目中不可能存在的情况写到后缀尝试列表中

  • 频率出现最高的文件后缀要优先放在最前面,以做到尽快的退出寻找过程

  • 在源码中写导入语句时,要尽可能的带上后缀,从而可以避免寻找过程。例如在你确定的情况下把 require(‘./data’) 写成 require(‘./data.json’)

Webpack 配置如下:

1
2
3
4
5
6
module.exports = {
resolve: {
// 尽可能的减少后缀尝试的可能性
extensions: ['js'],
},
};

2.使用 cache-loader,将结果缓存中磁盘中

在一些性能开销较大的 loader 之前添加 cache-loader,将结果缓存中磁盘中。默认保存在 node_modueles/.cache/cache-loader 目录下。它所做的事情很简单,就是 babel-loader 开启 cache 后做的事情,将 loader 的编译结果写入硬盘缓存。再次构建会先比较一下,如果文件较之前的没有发生变化则会直接使用缓存。

安装:

1
npm i cache-loader -D

cache-loader 的配置很简单,放在其他 loader 之前即可。修改Webpack 的配置如下:

1
2
3
4
5
6
7
8
9
10
11
module.exports = {
module: {
// 例如 babel-loader 耗时比较长,给它配置 cache-loader 放在 loader 之前
rules: [
{
test: /\.jsx?$/,
use: ['cache-loader','babel-loader']
}
]
}
}

如果只打算给 babel-loader 配置 cache 的话,也可以不使用 cache-loader,给 babel-loader 增加选项 cacheDirectory。

cacheDirectory:默认值为 false。当设置为 true 时,指定的目录将用来缓存 loader 的执行结果。之后的 Webpack 构建,将会尝试读取缓存,来避免在每次执行时,可能产生的、高性能消耗的 Babel 重新编译过程。使用默认缓存目录:node_modules/.cache/babel-loader

使用方法:

1
loader: 'babel-loader?cacheDirectory=true'

3.使用 happypack 开启多进程打包

受限于 Node 是单线程运行的,所以 Webpack 在打包的过程中也是单线程的,特别是在执行 Loader 的时候,解析转换以及代码的压缩中的时间很长,这样就会导致构建时间变长。

HappyPack 的基本原理是将这部分任务分解到多个子进程中去并行处理,子进程处理完成后把结果发送到主进程中,从而减少总的构建时间:

安装

1
npm i happypack -D

修改配置文件:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
const Happypack = require('happypack');
module.exports = {
module: {
rules: [
{
test: /\.js[x]?$/,
use: 'Happypack/loader?id=js',
include: [path.resolve(__dirname, 'src')]
},
{
test: /\.css$/,
use: 'Happypack/loader?id=css',
include: [
path.resolve(__dirname, 'src'),
path.resolve(__dirname, 'node_modules', 'bootstrap', 'dist')
]
}
]
},
plugins: [
new Happypack({
id: 'js', // 和rule中的 id=js 对应
// 将之前 rule 中的 loader 删除,在此配置
use: ['babel-loader'] //必须是数组
}),
new Happypack({
id: 'css',// 和rule中的 id=css 对应
use: ['style-loader', 'css-loader','postcss-loader'],
})
]
}

4.thread-loader

除了使用 Happypack 外,我们也可以使用 thread-loader ,把 thread-loader 放置在其它 loader 之前,那么放置在这个 loader 之后的 loader 就会在一个单独的 worker 池中运行。

在 worker 池(worker pool)中运行的 loader 是受到限制的。例如:

  • 这些 loader 不能产生新的文件。

  • 这些 loader 不能使用定制的 loader API(也就是说,通过插件)。

  • 这些 loader 无法获取 webpack 的选项设置。

安装:

1
npm i thread-loader -D

修改配置文件:

1
2
3
4
5
6
7
8
9
10
11
module.exports = {
module: {
// 配置 thread-loader 放在所有 loader 之前(包括 cache-loader)
rules: [
{
test: /\.jsx?$/,
use: ['thread-loader', 'cache-loader', 'babel-loader']
}
]
}
}

5.使用 hard-source-webpack-plugin 为模块提供中间缓存

HardSourceWebpackPlugin 为模块提供中间缓存,缓存默认的存放路径是: node_modules/.cache/hard-source。

配置 hard-source-webpack-plugin,首次构建时间没有太大变化,但是第二次开始,构建时间大约可以节约 80%。

安装依赖:

1
npm i hard-source-webpack-plugin -D

修改配置文件:

1
2
3
4
5
6
7
//webpack.config.js
var HardSourceWebpackPlugin = require('hard-source-webpack-plugin');
module.exports = {
plugins: [
new HardSourceWebpackPlugin()
]
}

需要注意的是 hard-source-webpack-plugin 存在一些坑,如果遇到某些配置不生效了,例如热更新失效,或者某些配置不生效等,可以查看HardSourceWebpackPlugin文档 ,文档中列出了一些你可能会遇到的问题以及如何解决。

6.使用 IgnorePlugin 忽略第三方包指定目录

IgnorePlugin 是 webpack 的内置插件,作用是忽略第三方包指定目录。例如: moment (2.24.0版本) 会将所有本地化内容和核心功能一起打包,我们就可以使用 IgnorePlugin 在打包时忽略本地化内容。

1
2
3
4
5
6
7
//webpack.config.js
module.exports = {
plugins: [
// 忽略 moment 下的 ./locale 目录
new webpack.IgnorePlugin(/^\.\/locale$/, /moment$/)
]
}

忽略 moment 下的 ./locale 目录后,如果我们需要指定语言,那么需要我们手动的去引入语言包,例如,引入中文语言包:

1
2
import moment from 'moment';
import 'moment/locale/zh-cn';// 手动引入自己需要的语言包

index.js 中只引入 moment,打包出来的 bundle.js 大小和配置了 IgnorePlugin,单独引入 moment/locale/zh-cn,构建出来的包大小为大概差距有 200k 左右。

7.关于使用 webpack-parallel-uglify-plugin 增强代码压缩

在 Webpack3 中,我们一般使用 UglifyJS 来压缩代码,但是这个是单线程运行的,为了加快效率,我们可以使用 webpack-parallel-uglify-plugin 来并行运行 UglifyJS,从而提高效率。

但是在 webpack4.x 内置默认使用 TerserWebpackPlugin,在 mode 设置为 production 就会默认开启 TerserWebpackPlugin,所以可以不用配置 webpack-parallel-uglify-plugin

减少打包文件体积

引入 webpack-bundle-analyzer 分析打包后的文件

借助 webpack-bundle-analyzer 可以分析打包后的文件,判断哪些包体积过大,是否可以拆分和优化

安装依赖:

1
npm i webpack-bundle-analyzer -D

使用也很简单,修改我们的配置文件:

1
2
3
4
5
6
7
8
9
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
module.exports = {
plugins: [
new BundleAnalyzerPlugin({
analyzerHost: '127.0.0.1', // 默认这两个配置都可以不配
analyzerPort: 8889 // 默认 8888
}),
]
}

接下来在 package.json 里配置启动命令 (不配置也可以,npm run build 打包时,会默认打开: http://127.0.0.1:8888/)

1
"analyz": "NODE_ENV=production npm_config_report=true npm run build"

复制代码 windows 请安装 npm i -D cross-env

1
2
3
4
5
6
7
8
9
10
11
12
13
"analyz": "cross-env NODE_ENV=production npm_config_report=true npm run build"
```

复制代码接下来 npm run analyz 浏览器会自动打开文件依赖图的网页

### 1.使用 externals 配置,然后将 JS 文件、CSS 文件和存储在 CDN

如果我们想引用一个库,但是又不想让 webpack 打包,并且又不影响我们在程序中以 CMD、AMD 或者 window/global 全局等方式进行使用,那就可以通过配置 Externals。这个功能主要是用在创建一个库的时候用的,但是也可以在我们项目开发中充分使用 Externals 的方式,我们将这些不需要打包的静态资源从构建逻辑中剔除出去,而使用 CDN 的方式,去引用它们。

官方案例:

```html
<script src="https://code.jquery.com/jquery-3.1.0.js"></script>
1
2
3
4
5
6
7
8
9
module.exports = {
//...
externals: {
jquery: 'jQuery'
}
};

// 这里需要注意,’:’ 号后面对应的文件名必须和项目里面 import 引入的文件昵称相同,例如: import Vue from 'vue' 就是上面对应的 'vue': 'Vue'。
// 这里特别注意一下 element-ui 的昵称必须是: ‘ELEMENT’, 如果使用其它昵称将报错。具体看 element-ui 源码导出方式你就懂了~
1
2
3
// 项目中也可以正常 import
import $ from 'jquery';
$('.my-element').animate(/* ... */);

在项目中经常把各种库文件使用 CDN 加载,然后通过 html-webpack-plugin 插入到模板页面中。

2.使用 DllPlugin(动态链接库)将 bundles 拆分

有些时候,如果所有的JS文件都打成一个JS文件,会导致最终生成的JS文件很大,这个时候,我们就要考虑拆分 bundles。

使用 DllPlugin(动态链接库)将 bundles 拆分,使用 DllReferencePlugin(索引链接) 对 manifest.json 引用,让一些基本不会改动的代码和不会频繁更新的库先打包成静态资源,避免反复编译浪费时间。例如我们将 react 和 react-dom 单独打包成一个动态链接库:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
const webpack = require('webpack');
const path = require('path');

module.exports = {
entry: {
react: ['react', 'react-dom']
},
mode: 'production',
output: {
filename: '[name].dll.[hash:6].js',
path: path.resolve(__dirname, 'dist', 'dll'),
library: '[name]_dll' // 暴露给外部使用
// libraryTarget 指定如何暴露内容,缺省时就是 var
},
plugins: [
new webpack.DllPlugin({
// name 和 library一致
name: '[name]_dll',
path: path.resolve(__dirname, 'dist', 'dll', 'manifest.json') //manifest.json 的生成路径
})
]
}

3.使用 optimization.splitChunks 配置抽离公共代码

抽离公共代码是对于多页应用来说的,如果多个页面引入了一些公共模块,那么可以把这些公共的模块抽离出来,单独打包。公共代码只需要下载一次就缓存起来了,避免了重复下载。

抽离公共代码是 webpack 内置的,在 optimization.splitChunks 中配置:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
module.exports = {
optimization: {
splitChunks: {// 分割代码块
cacheGroups: {
vendor: {
// 第三方依赖
priority: 1, // 设置权重,首先抽离第三方模块
name: 'vendor',
test: /node_modules/,
chunks: 'initial',
minSize: 0,
minChunks: 3 //最少引入了3次
},
//缓存组
common: {
// 公共模块
chunks: 'initial',
name: 'common',
minSize: 10, // 大小超过10个字节
minChunks: 2 // 最少引入了2次
}
}
}
}
}

4.使用 IgnorePlugin 忽略第三方包指定目录,例如 moment 的本地语言包(重复)

IgnorePlugin 也有减少打包文件体积的作用,这里也列出来,但是和上加快构建速度一样,就不再重复说明

5.使用 url-loader 和 image-webpack-loader 对图片进行转化和压缩处理

如果本地图片比较多的话,采用 image-webpack-loader 压缩后,再对比较小的图片根据 url-loader 来进转化为 base64 格式,可以有效减少打包文件的体积和图片的 http 请求数量。

配置(注意 loader 从上到下,先右后左执行):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
module.exports = {
module: {
rules: [
{
test: /\.(png|gif|jpe?g|svg)$/i,
exclude:[path.resolve(process.cwd(), 'src/assets/css')],
use: [
{
loader: 'url-loader',
options: {
limit: 1024,
name: '[hash:8].[ext]',
useRelativePath: false,
outputPath: function(fileName){
return 'assets/images/'+fileName
}
}
},
{
loader:'image-webpack-loader'
}
]
}
]
}
}

6.优化 source map

什么是 source map

我们打包,将开发环境中的源代码经过压缩,去空格,babel 编译转化,最终可以得到适用于生产环境的代码。但这样处理后的代码和源代码之间存在很大的差异,难以阅读且无法 debug。

如果压缩等处理过的生产环境中的代码出现 bug,那么调试的时候只能定位到压缩处理后的代码的位置,无法定位到开发环境中源码位置。source map 就是为解决上述的代码定位问题。方便开发人员 debug,定位错误。

在 webpack 中提供了十几种 source map 的组合:

source_map图

+++ 非常快速, ++ 快速, + 比较快, o 中等, - 比较慢, – 慢

其中一些值适用于开发环境,一些适用于生产环境。对于开发环境,通常希望更快速的 source map,需要添加到 bundle 中以增加体积为代价,但是对于生产环境,则希望更精准的 source map,需要从 bundle 中分离并独立存在。

在不同环境中如何选择 source map 的类型

  1. 首先在源代码的列信息是没有意义的,只要有行信息就能完整的建立打包前后代码之间的依赖关系。因此,不管是开发还是生产环境都会增加 cheap 属性来忽略模块打包后的列信息关联

  2. 不管是生产环境还是开发环境,我们都需要定位 debug 到最原始的资源,比如定位错误到 jsx,ts 的原始代码,而不是经编译后的 js 代码。所以不可以忽略掉 module 属性

  3. 需要生成 .map 文件,所以得有 source-map 属性

所有有:

  • 开发环境推荐使用:cheap-module-eval-source-map

  • 生产环境推荐使用:cheap-module-source-map

更详细的介绍请看官网:devtool

7.按需加载,

在 vue 和 react 单页面项目中,我们一般会通过路由懒加载来实现按需加载,这里就不再赘述

8. webpack4.x 后版本自身的优化:

Tree Shaking

Tree Shaking 可以实现删除项目中未被引用的代码,即会自动移除没有使用到的代码

1
2
3
4
5
// test.js
export const a = 1
export const b = 2
// index.js
import { a } from './test.js'

对于以上情况,test 文件中的变量 b 如果没有在项目中使用到的话,就不会被打包到文件中。

如果你使用 Webpack4.x 的话,生产环境就会自动启动这个优化功能。

scope hosting 作用域提升,变量提升,可以减少一些变量声明

Scope Hoisting 会分析出模块之间的依赖关系,尽可能的把打包出来的模块合并到一个函数中去,在生产环境下,默认开启。

比如我们希望打包两个文件

1
2
3
4
// a.js
export const a = 1
// index.js
import { a } from './a.js'

对于这种情况,我们打包出来的代码会类似这样

1
2
3
4
5
6
7
8
9
10
[
/* 0 */
function (module, exports, require) {
//...
},
/* 1 */
function (module, exports, require) {
//...
}
]

使用 Scope Hoisting 的话,代码就会尽可能的合并到一个函数中去,也就变成了这样的类似代码

1
2
3
4
5
6
[
/* 0 */
function (module, exports, require) {
//...
}
]

这样的打包方式生成的代码明显比之前的少多了。如果在 Webpack4 中你希望开启这个功能,只需要启用 optimization.concatenateModules 就可以了,生产环境默认开启。

1
2
3
4
5
module.exports = {
optimization: {
concatenateModules: true
}
}

babel 配置的优化

配置 @babel/plugin-transform-runtime,重复使用 Babel 注入的帮助程序,以节省代码大小的插件。

在不配置 ·@babel/plugin-transform-runtime 时,babel 会使用很小的辅助函数来实现类似 _createClass 等公共方法。默认情况下,它将被注入(inject)到需要它的每个文件中。但是这样的结果就是导致构建出来的JS体积变大。

我们也并不需要在每个 js 中注入辅助函数,因此我们可以使用 @babel/plugin-transform-runtime@babel/plugin-transform-runtime 是一个可以重复使用 Babel 注入的帮助程序,以节省代码大小的插件。

因此我们可以在 .babelrc 中增加 @babel/plugin-transform-runtime 的配置:

1
2
3
4
5
6
7
8
{
"presets": [],
"plugins": [
[
"@babel/plugin-transform-runtime"
]
]
}

关于 webpack 5.x

虽然我们在项目中大部分童鞋可能还是使用的 4.x 版本,但是 webpack 当前最新的版本已经是 5.10.1 了,那么 5.x 版本主要更新了什么呢?

1.剔除npm包里面针对Node.js模块自动引用的Polyfills

Webpack 4.x 编译引入 npm 包,有些 npm 包里面包含针对 nodejs 的 polyfills,polyfill 会加到最终的 bundle 中,实际前端浏览器是不需要的,5.x 后的版本会自动剔除

Webpack 5.x 版本编译中,会出现 polyfill 添加提示,如果不需要 node polyfille,按照提示 alias 设置为 false 即可

1
2
3
4
5
6
7
8
9
10
11
// webpack.config.js
resolve: {
// 1.不需要 node polyfilss
alias: {
crypto: false
},
// 2.若需要,可以手动添加 polyfills
// fallback: {
// "crypto": require.resolve('crypto-browserify')
// }
}

2.长期缓存优化

Webpack 4.x 是根据代码的结构生成 chunkhash,现在 5.x 根据完全内容生成 chunkhash,比如改了内容的注释或者变量则不会引起 chunkhash 的变化,让浏览器继续使用缓存:

Webpack 5.x 针对 moduleId 和 chunkId 的计算方式进行了优化,增加确定性的 moduleId 和 chunkId 的生成策略。moduleId 根据上下文模块路径,chunkId 根据 chunk 内容计算,最后为 moduleId 和 chunkId 生成 3 ~ 4 位的数字 id,实现长期缓存,生产环境下默认开启。

3.持久缓存优化

在 Webpack 4.x 我们一般采用 cache-loader 或者 babel-loader 自带的 cacheDirectory 来进行缓存操作,在 Webpack 5.x 中缓存默认是 memory,你可以修改设置写入硬盘:

1
2
3
4
5
6
7
8
9
module.exports = { 
cache: {
// 1. 将缓存类型设置为文件系统
type: 'filesystem', // 默认是memory
// 2. 将缓存文件夹命名为 .temp_cache,
// 默认路径是 node_modules/.cache/webpack
cacheDirectory: path.resolve(__dirname, '.temp_cache')
}
}

第一次构建是一次全量构建,它会利用磁盘模块缓存(以空间换时间),使得后续的构建从中获利

续构建具体流程是:读取磁盘缓存 -> 校验模块 -> 解封模块内容。

4.更好的Tree Shacking(构建优化)

现在有这样一段代码:

1
2
3
4
5
6
7
8
9
10
11
// inner.js
export const a = 'aaaaaaaaaa';
export const b = 'bbbbbbbbbb';

// module.js
import * as inner from "./inner";
export { inner };

// index.js
import * as module from "./module";
console.log(module.inner.a);

在 Webpack 4.x 中毫无疑问,以上代码 a、b 变量是被全部打包的。但我们只调用了 a 变量,理想情况应该是 b 被识别为 unused,不被打包。这一优化在 Webpack 5.x 中实现了。 在 Webpack 5.x 中会分析模块 export 与 import 之间的依赖关系,最终的代码生成非常简洁:

1
!function(){"use strict";console.log("aaaaaaaaaa")}();

5.Module Federation(模板联邦)

上面 4 点优化都是对 webpack 常规优化,而 Module Federation 就是 Webpack 5.x 中的重大的变革了

Module Federation 让 Webpack 达到了线上 runtime 的效果,让 chunk 直接在独立应用间利用 CDN 直接共享,不再需要本地安装 NPM 包、构建再发布了

之前我们希望共享代码是如何做的

  • NPM

维护一个 CommonComponents 的 NPM 包,在不同项目中安装、使用。如果 NPM 包升级,对应项目都需要安装新版本,本地编译,打包到 bundle 中

  • UMD

UMD 优点在 runtime。缺点也明显,体积优化不方便,容易有版本冲突

  • 微前端

独立应用间的共享也是问题。一般有两种打包方式:

1. 子应用独立打包,模块解耦了,但公共的依赖不易维护处理
2. 整体应用一起打包,能解决公共依赖;但庞大的多个项目又使打包变慢,后续也不好扩展

Webpack 5.x 实现了全新的解决方案

这个方案是直接将一个应用的 bundle,应用于另一个应用,动态分发 runtime 子模块给其他应用

使用方式如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
module.exports = {
// other webpack configs...
plugins: [
new ModuleFederationPlugin({
// 1. name 当前应用名称,需要全局唯一
name: "app_one_remote",
// 2. remotes 可以将其他项目的 name 映射到当前项目中
remotes: {
app_two: "app_two_remote",
app_three: "app_three_remote"
},
// 3. exposes 表示导出的模块,只有在此申明的模块才可以作为远程依赖被使用
exposes: {
AppContainer: "./src/App"
},
// 4. shared可以让远程加载的模块对应依赖改为使用本地项目的 React或ReactDOM。
shared: ["react", "react-dom", "react-router-dom"]
}),
new HtmlWebpackPlugin({
template: "./public/index.html",
chunks: ["main"]
})
]
};

比如设置了 remotes: { app_two: "app_two_remote" },在代码中就可以直接利用以下方式直接从对方应用调用模块:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
import { Search } from "app_two/Search";
app_two/Search来自于app_two 的配置:

// app_two的webpack 配置
export default {
plugins: [
new ModuleFederationPlugin({
name: "app_two",
library: { type: "var", name: "app_two" },
filename: "remoteEntry.js",
exposes: {
Search: "./src/Search"
},
shared: ["react", "react-dom"]
})
]
};

正是因为 Search 在 exposes 被导出,我们因此可以使用 [name]/[exposes_name] 这个模块,这个模块对于被引用应用来说是一个本地模块。

更多请参考官网 Module Federation

参考链接:

带你深度解锁Webpack系列(优化篇)

深入浅出 Webpack

Webpack5 上手测评